Chapter 1
Types of Diagrams for Representing Structures of Cooperative Systems
= Fundamental Modeling Concepts (FMC)



Home 		1.1
Two
Problems 		1.2
Concept of
the Solution 		1.3
Composition-
Diagrams 		1.4
Process-
Diagrams 		1.5
Data-
Structure-
Diagrams 		1.6
Metadiagram
of the FMC-Diagrams 		1.7
Layering of
Interpreters 		1.8
Separation
of Phases

1.1 Two Problems

1.1.1 The Primary Problem

In 1973, my friend Dietrich Klugmann introduced me to the software developed by the company Siemens on the occasion of the 1972 Olympics in Munich. With the development of this software, approximately 150 project workers were involved over a period of almost three years. Thus, design and implementation of this software required an effort of about 400 person years. The paper stack with the printed program code had a height of about 2 meters. This was the first time that I got aware of the problem that nobody knew how to efficiently communicate the structures of such large software systems. There was not much imagination required to come up with the following three questions:

(1) On the basis of which documents can the subtasks be defined if the system to be created can only be realized with a high degree of division of labor?
(2) Which documents can be used to train those who are to be recruited into the development team during the course of the project?
(3) How can people who have not been involved in the design and implementation process of the original software later acquire the knowledge they need
to correct errors or to add new functions?

These three questions could be easily answered if the considered system were not a software system but a building or a machine. Because then, graphic representations would have been created before the system was implemented which then would have been used to guide the engineers during the implementation process. Immediately, it was clear to me that graphic representations were needed as well in the field of software systems engineering, but no one at that time had any idea how such representations could look. Today, software systems are in use, whose program code, if printed, would result in a stack of paper reaching the height of the Eiffel Tower in Paris (1,000 ft). It is absolutely impossible to efficiently communicate such systems without the use of suitable graphical representations.

1.1.2 The Secondary Problem

The secondary problem is given by the fact that nobody in the academic world of computer science is really interested in the primary problem. Most engineers who are unfamiliar with the world of software development, are very surprised when they come to know that easily readable standardized graphical representations of large software systems are no subject taught in computer science education in 2016. In my effort to solve the primary problem, I was understandably always looking for allies in the academic world of computer science. Unfortunately, this long-term search was unsuccessful, and so I asked myself what the reasons for this disinterest might be. In the meantime, I think I have discovered three causes of this disinterest.

(1) The pride of the programmers of their running programs
For beginners, programming does not require an above-average talent, so they can already have their first success stories quite early. And these success stories can become addictive, because the programmers now experience themselves as people who can impose their will on the computer. In my lectures on programming, I have seen it again and again that the students urged me to abbreviate my introductory explanations, boring in their view, and finally teach them to write their first program. Many programmers soon get convinced that "getting the program to run" is the only thing which matters, and that any additional effort is an unnecessary ballast. In this attitude, they get confirmed by the applause of outsiders, who admire them like magicians in the circus.

(2) Computer science professors view their field as "the science of interpreted formalisms".
In the early years, the capacity of computer memories was still so limited that they could only contain as much software as a single programmer could develop in half a year. Therefore, the problem of mastering the complexity of large software systems did not yet exist. At that time, the problems related to software were exclusively mathematical-logical. Therefore, it was quite natural that academic computer science was established by mathematicians and that they defined the teaching contents and research topics of the new discipline. Therefore, it is not surprising that their approach to the problem of complexity consists in searching suitable formalisms and algorithms. The experience of classical engineers with easily readable standardized graphical representations is not considered relevant in their field. A renowned computer science professor once told me that my work was in the field of management.
Very often, it is pointed out that the tool-supported methods UML (Unified Modeling Language) and SysML (System Modeling Language) would eliminate the need for other methods such as FMC which is presented here. It is not the space here for the compelling arguments that I can make against this claim.

(3) The lack of natural visibility of the systems to be represented
In the construction industry and in the mechanical engineering sector, the systems to be designed are structures that have a natural visibility, so that the graphical representations only need to represent - in a slightly abstracted and symbolized form - what will be seen later when the completed system can be looked at. However, this is not the case in software, since the only thing that can be seen later is the readable program code. Here, the graphical representations must show the mental "building of thoughts" which arose in the minds of the system architects during planning considerations. Even at the risk of being considered arrogant, I argue that only a small fraction of those working in the software sector have the necessary abstraction ability and the necessary didactic skill to design the necessary graphical representations in sufficient quality. I am even convinced that many of those who are teaching computer science do not have those skills.

The three arguments presented above seem to leave no hope at all that using easily readable graphical representations for providing more efficient communication about large software systems has a chance to become one day self-evident in the software industry. Nevertheless, I see good reasons for not giving up hope. In particular, the fact that only a few experts have the ability to design useful graphical representations is not a serious obstacle, because the few who have it are completely sufficient to meet the demand. All others in the software industry do not need to create such representations; they only have to read them, and almost everyone can do this.

My optimistic opinion about FMC's prospects is based on my experience with executives in the software industry. I often had the opportunity to introduce the concept of FMC to such executives, and most often, they had no problems to understand the concepts and to see the benefits. Some of them then explored ways to introduce FMC into their company. But they soon had to recognize that they could not overcome the passive resistance of their subordinates. These subordinates, understandably, do not want to give up the advantages which they derive from not sharing their knowledge. And they know very well that they are not replaceable for the company, so their superiors can not force them to use FMC.

I suppose that it is actually impossible to change the situation today. However, I am convinced that the problems arising from the lack of easily readable graphical representations for communicating the structures of large software systems become more and more obvious and expensive so that those who suffer from the situation will one day seek the guilty ones. And they will find these among those who are responsible for the contents of the computer science curriculum. These will then no longer be able to deny the need for easily readable standardized graphical representations, and they will finally give them the appropriate weight in the curricula.

to the top